Extensible Markup Language (XML) has become a widespread file format for a large number of office-productivity tools, as well as for various types of Internet Protocol (IP) multimedia services, which may be distributed e.g. via the IP Multimedia Subsystem (IMS), or any other architectural framework which is adapted for delivery of IP multimedia services. The XML Configuration Access Protocol (XCAP) allows a device provided with XCAP Client functionality to read, write and modify application configuration data stored in XML format on a Server which is provided with XCAP Server functionality.
XML Document Management (XDM) is an Open Mobile Alliance (OMA) specification which enables XCAP Clients to access and manipulate XML documents stored on XCAP Servers. According to the OMA XDM standard, a Client having XCAP Client functionality may be referred to as an XDM Client (XDMC), while a corresponding Server may be referred to as an XDM Server (XDMS).
Via XCAP an XDMC can modify a document e.g. by adding content to, or modifying a part of an XML document, typically referred to as an XML node. Such a modification may typically be achieved by using an XCAP PUT message for delivering the respective content from the XDMC to the XDMS.
FIG. 1 is an illustration of a typical scenario for such a modification, where an XDMC 100 requires an update of an XML node in an XML document which is already stored at an XDMS 101. XDMC 100 stores the respective XML node content locally before a request, typically in the form of an XCAP PUT, is sent to XDMS 101, via an Aggregation Proxy (AP) 102, as indicated with steps 1:1 and 1:2. In a next step 1:3, the XML node of the relevant XML document is modified according to conventional modification procedures.
In subsequent steps 1:4 and 1:5, the executed modification is notified to other XDMCs, here represented by XDMC 104. Such a notification may typically be executed by transmitting a respective SIP Notify to each respective XDMC that is to be notified.
If the update is of a temporary nature, XDMC 100 has to stay on line and wait until the required time which specifies the duration of the temporary update has elapsed. Thereafter XDMC 100 has to repeat steps 1:1 and 1:2, once again, as indicated with steps 1:6 and 1:7, respectively in FIG. 1. This time, however, the request is provided with the XML node content which was valid prior to the first modification, to enable the XDMC to use this content to undo the previous update. A specific scenario where such an aspect may be of relevance is e.g. when a specific user is to be blocked from a service, but only for a limited time interval, after which the blocked user will again be admitted to use the service.
Since XCAP requires that it is the XDMC that updates the XDMS, problems may occur e.g. if the XDMC runs out of batteries, or is switched off prior to expiry of the stated expire time. In such a situation, an XML node of an XML document that was intended to have a limited validity, may instead erroneously remain in the document for a long time.
Present mechanisms for enabling time limited modification also requires complex functionality in the XDMC.